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PKI- BASED CLIENT/ SERVER AUTHENTICATION 
BACKGROUND 

This disclosure relates to public-key infrastructure 
(PKI) -based client/server authentication. 

The expanding popularity of the Internet, especially 
the World Wide Web, has lured many people and businesses 
into the realm of network communications. There has been a 
corresponding growth in the transmission of confidential 
information over these networks. As a consequence, there is 
an increasing need for security in communications over the 
Internet. In particular, there is a critical need for 
improved approaches to ensuring the confidentiality of 
private information . 

Many operating systems, including UNIX and Microsoft 
Windows™, support a security protocol implemented through a 
Secure Sockets Layer (SSL) library. In these systems, the 
SSL provides authentication and data privacy over the 
Internet. However, SSL implementation has some 
disadvantages. The SSL 1.0 provides server authentication 
but not client authentication. The SSL 3.0 provides 
mechanisms for client authentication but requires storage 
and management of client certificates. 

For example, Web browsers that support the SSL 3.0 warn 
the user of connecting to a site with an unlisted 
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certificate. An unlisted certificate site refers to a site 
with a certificate signed by a certificate authority not in 
the authority trust list such as CyberTrust or Verisign. In 
this case, the browser requires the user's certificate to be 
placed into the client certificate list. The browser 
further requires the selection of this certificate every 
time a connection is made to the web server. 

Public-key infrastructure (PKI) is a combination of 
software, encryption technologies, and services that 
provides security for communications and business 
transactions over public and private networks. The PKI 
technology provides several aspects of security needs such 
as authentication, privacy, data integrity, and non- 
repudiation. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Different aspects of the disclosure will be described 
in reference to the accompanying drawings wherein: 

FIG.l shows an examplary computer network in accordance 
with an embodiment of the present invention; 

FIG. 2 is a block diagram of a PKI -based client /server 
authentication (PBCSA) system in accordance with an 
embodiment of the present invention; 
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FIGS. 3A through 3C show an authorization process 
according to an embodiment of the present invention; 

FIG. 4 is a flowchart of a process to build 
communication privacy according to an embodiment of the 
present invention; 

FIG. 5A shows one example of a PBCSA initial handshake 
protocol for a Web browser client; 

FIG. 5B shows one example of a PBCSA initial handshake 
protocol for a WinlNET-based component client; 

FIGS. 6A through 6E show a detailed example technique 
for a security filter in accordance with an embodiment of 
the present invention; and 

FIG. 7 is a detailed example technique for a security 
extension in accordance with an embodiment of the present 
invention. 

DETAILED DESCRIPTION 

Throughout this description, the embodiments and 
examples shown should be considered as examples rather than 
as limitations of the invention. 

An examplary computer network 100, such as the 
Internet, is illustrated in FIG. 1 in accordance with an 
embodiment of the present invention. The computer network 
100 includes computers 102, 104, 106. The computers 102 may 
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be "personal computers" or workstations. These computers 
102 may enable users to make requests for data or services 
from other computers on the network 100. The requested data 
may reside in the computers 102, 104, 106. The computer 
network 100 also includes a network channel 108, which 
allows the delivery of the requested data or service between 
the computers 102, 104, 106. 

In some embodiments, the computers 102 are client 
systems and the computers 104, 106 are servers. The term 
"client" refers to a computer's general role as a requester 
of data or services, and the term "server" refers to a 
computer's role as a provider of data or services. The size 
of a computer, in terms of its storage capacity and 
processing capability, does not necessarily affect its 
ability to act as a client or server. Further, it is 
possible that a computer may request data or services in one 
transaction and provide data or services in another 
transaction, thus changing its role from client to server or 
vice versa. 

In other embodiments, the computers 102 may also act as 
consoles to provide system administrators with access to 
managed nodes. The managed nodes may be represented with 
any computers 102, 104, 106 tied to the network channel 108. 
In these embodiments, the consoles and the managed nodes may 
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have associated servers to store related data. There may 
also be a central service and database server referred to as 
a core . The core may be used to store and manage data . The 
core may also be used to provide authentication and issue 
certificates. The console, the managed nodes, and the core 
may form a system such as Intel 1 s LANDesk product . 

The system described above may also require Single 
Sign-On (SSO) for the system administrator. Once the 
administrator logs into the core through the console, the 
SSO allows the administrator free access to the managed 
nodes in the system. The administrator is allowed to access 
the resources and administrative features of the system 
without requiring additional authentication processes at the 
core or the managed nodes. Thus, the authentication at the 
core is propagated to the managed nodes. 

The console in the system may use a Web browser or a 
WinlNET-based User Interface (UI) component, such as 
Microsoft Management Console (MMC) , to interface with the 
network. The managed node may use the Web server to 
communicate to the network. 

In the above embodiments, the system uses a PKI -based 
technology. The console performs network operating system 
(NOS) authentication at the core computer using the 
capabilities of the core's web server. Once the operating 
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system has been authenticated, the console may create a 
public/private key pair and submit the public key to the 
core. The core may create an X.509 compliant certificate 
using the public key, and place identification information 
in the certificate based upon the NOS authenticated console 
session* Managed nodes have the core's signing certificate 
containing the core's public key. Therefore, the nodes may 
be configured to trust certificates signed by the core. 
When a managed node is contacted, the console may present 
the certificate to the managed node. The node may use the 
public key of the core to verify the certificate that 
identifies the operator/administrator. Further, the managed 
node may use the information embedded in the certificate to 
grant specific access rights to the console operator. 

A PRI-based client/server authentication (PBCSA) system 
utilizes the Web server's extension functionality and the 
Web browser's script capabilities to implement the PBCSA 
protocol. A block diagram of the PBCSA system 2 00 is 
illustrated in FIG. 2 in accordance with an embodiment of 
the present invention. The diagram includes the PBCSA 
system 200 in the context of a relationship between a client 
202 and a server 204. In one embodiment, the PBCSA system 
includes a security plug-in 206, a web server security 
filter 208, and a web server security extension 210. 
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The web server security filter 208 monitors sessions 
for proper authentication. The security filter 208 may also 
re-direct unauthenticated sessions to the proper web page. 
The security plug-in 206 interfaces a client script to 
5 generate public/private key pairs. The security plug-in 2 06 
may also receive and store certificates from the core. The 
security plug-in 206 may further generate client signatures. 

The web server security extension 210 generates an HTML 
and browser script commands to cause the client 2 02 to 
10 perform the required steps . 

FIGS. 3A through 3C show a flowchart of an 
authorization process according to an embodiment of the 
*y present invention. The authorization process includes a 

01 console authentication and a client authorization. 

is 

q is Initially, a client side console submits a request to a 

managed node's web server at 3 00. The security filter 2 08 
checks the request's destination at 302. If the destination 
is a protected page 304, the security filter 208 may examine 
the request to look for a valid security token at 306. The 
20 presence of the token may indicate a previous authentication 
by the console. If the valid security token is not present 
to indicate a previous authentication 308 r then the security 
filter 208 may re-direct the request to the security 
extension 210 of the managed node's web server at 310. In 
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one embodiment, the re-direction is effected by an 
appropriate HTML program. 

At 312, the security filter 208 may generate an 
appropriate re-direct HTML program and script to direct the 
client to invoke the security plug-in 206. The invocation 
of the security plug- in 206 allows the client to submit the 
certificate to the security extension at 314. The security 
extension 210 may then verify the certificate by checking 
the certificate's signature with the trusted core's 
certificate at 316. If the certificate is determined to be 
valid 318, the security extension 210 creates a connection 
session at 320. The security extension 210 may then perform 
a server challenge at 322. In one embodiment, the server 
challenge may be made by using the re-direct HTML program to 
convey the challenge to the client. The re-direct HTML 
program may direct the client to invoke the security plug-in 
2 06 to generate the client response to the server challenge 
at 324. 

The purpose of the server challenge and the client 
response is to prevent an intruder from intercepting the 
client certificate and then submitting the certificate to 
the server. In one embodiment, the server challenge is a 
random number. The client may respond to the server 
challenge by signing the random number with a private key 
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associated with the session certificate. By verifying that 
the client has the private key, the server knows that the 
client is not an eavesdropper. An eavesdropper may obtain 
the certificate by listening to network traffic, but he has 
no access to the private key since the key is not sent over 
the network. 

The re-direct HTML program may direct the client to 
save the security token as a named cookie at 326. At 328, 
the client is directed to re-submit the Uniform Resource 
Locator (URL) of the originally requested page, along with a 
query string to the server. Once this process is completed, 
the security filter 208 determines if the session is 
authenticated. The determination is made using the security 
token contained in the cookie at 33 0. 

Once the session is authenticated, the security filter 
208 determines if the client is authorized to access the web 
page at 332. If authorized, the client is allowed access to 
the requested page at 334. 

FIG. 4 shows a flowchart of a process to build data 
communication privacy according to an embodiment of the 
present invention. A determination of the identity of the 
PBCSA client is made at 400. 

If the client is a WinlNET-based component, the 
security filter 208 may generate a symmetric key and encrypt 
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the key with the client's public key at 402. The filter may 
then send the encrypted symmetric key to the client via an 
hypertext transfer protocol (HTTP) header or cookie at 404. 
The symmetric key may be used to encrypt communication at 
406. If the client is a web browser, the PBCSA system may 
work with Secure Sockets Layer (SSL) library 1 . 0 to provide 
communication privacy at 408. 

The combination of SSL 1.0 and the PBCSA system allows 
flexibility of an extensive client/server authentication 
without added responsibility of certificate selection and 
management. The combined system provides advantageous 
features of communication authentication and privacy at 
significantly reduced storage and management tasks for the 
client. The footprint of the server side component is 
smaller than that of a fully enable SSL 3.0 server. The 
PBCSA system may also provide authentication to non-SSL 
supported Web servers. Further, the PBCSA system may enable 
core-based authorizations. 

FIGS. 5A and 5B show examples of a PBCSA initial 
handshake protocol. The handshake for a Web browser client 
(FIG. 5A) may start with the client first contacting the 
server with a request to an URL of the server. The security 
filter 208 then redirects the request to the security 
extension 210. The client may submit the session 
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certificate to the security extension 210. The security 
extension 210 then verifies the certificate and generates a 
server challenge. The security extension 210 redirects the 
client to its original URL. The client may then generate 
the client response and save the response as a named cookie. 

For a WinlNET-based component (FIG. 5B) , the client 
first contacts the server with the certificate inserted as a 
request header. The security filter 2 08 may verify and 
generate the server challenge that is inserted in the 
response header. The client may then generate the client 
response and save it as a named cookie. 

FIGS. 6A through 6E show a detailed example technique 
for the security filter 208. The duty of the security 
filter 208 is to protect certain areas (e.g. Web pages) on 
the server by blocking unauthenticated or unauthorized 
client accesses. 

The security filter 2 08 waits for Internet Server 
Application Programming Interface (ISAPI) Uniform Resource 
Locator (URL) map notifications at 600. The filter may then 
check if the URL is protected 602. If the URL is not 
protected, the request is allowed to proceed at 604. If the 
URL is protected, the filter may check the HTTP header at 
606. 
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If the HTTP header has a HTTP_LDMSCert variable, then 
the client is a non-browser client who submitted the 
certificate in the request header. The HTT P_LDM S C e r t 
variable inserts the client certificate into the HTTP 
header. The variable also informs the web server that the 
connection is made by a WinlNET-based client. When the 
security filter 208 finds this variable in the HTTP header, 
the filter assumes that the connection is a new WinlNET 
connection. The filter further expects the authentication 
to take place within the security filter 208. Thus, in this 
case, the security filter 208 does not need to redirect the 
client to submit the certificate to the security extension 
210. This saves a round trip between the web server and the 
client . 

The security filter 208 may then perform the 
verification of the certificate at 608. If the verification 
of the certificate 610 fails, the filter may reject the 
client at 612. If the verification succeeds, the filter may 
generate the node challenge 614 and add the challenge to the 
HTTP response header as a cookie variable at 616. The 
security filter 2 08 may respond to the client with a retry 
status at 618. The client may re-submit the request with 
the client response as the cookie variable instead of the 
certificate variable in the requested header at 620. The 
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re -submission of the request allows the client to present 
the authentication token to the server at 622. The security 
filter 208 may then create and register the session, and re- 
direct the client to the original URL. 

If the HTTP header does not have the HTT P_JLDMS Cert 
variable, then a check is made to find out if the client has 
presented an authentication token as a cookie variable at 
624. If the token is not present and the client is a Web 
browser 626, the security filter 208 may redirect the client 
to the security extension 210 for authentication at 628. If 
the client is not a browser, the filter may return an 
authentication failure status code at 63 0. The non-browser 
client automatically responds to this status code at 632. 
The client may then insert its session certificate in the 
HTTP__LDMS Cert header and resubmit the request at 634. 

If the authentication token is present, the filter may 
verify that the authentication token of the client response 
is valid at 636. The security filter 208 may then reject 
the client's access at 638 if the response is not valid. 
Otherwise, if the response is valid, the filter may verify 
that the authentication token has not expired at 640. If 
the token has expired, the filter may redirect the browser 
client 642 to the security extension at 644. For a non- 
browser client, the filter may respond to the client with a 
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failure status at 646. The client may insert a session 
certificate as the HTTP_LDMSCert variable, at 648, and 
resubmit the request to the managed node upon receipt of the 
failure status at 650. 

At 652, Access Control List (ACL) checking is performed 
to verify that the client is authorized to access the URL in 
the manner requested. If the client passes the 
authorization process 654, the client is allowed to proceed 
to the requested page at 656. Otherwise, the request is 
rejected at 658. 

FIG. 7 is a detailed example technique for the security 
extension 210. The duty of the security extension 210 is to 
obtain and verify the client's certificate when the client 
is a Web browser. The security extension 210 may then 
redirect the client to its original URL. 

The security extension 210 may obtain the certificate 
from the submitted form at 700. The extension 210 then 
verifies the certificate using the trusted core certificate 
at 702. If the verification fails at 704, the security 
extension 210 indicates a failure status to the client using 
an HTML program at 708. If the verification passes at 704, 
the security extension 210 creates and registers a new 
authenticated session at 706. The filter may then validate 
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this authenticated session by verifying the authentication 
token at 710 . 

The security extension 210 may generate a node 
challenge random number at 712. The extension 210 may also 
generate the re-direct HTML program. The program may 
generate the client response and save the response as a 
browser cookie at 714, and re-direct the client to the 
original URL it requested at 716. The browser cookie may be 
saved to expire after the current session. The Web browser 
or WinlNET component may automatically send the client 
response as a cookie variable in subsequent requests to the 
server . 

The Web browser may use the re-direct HTML program to 
redirect the browser from its requested target to the 
security extension 210 and from the extension 210 back to 
the original target during the authentication process. 

An example HTML code for the re-direct program is 
listed below. The following code segment contains HTML 
redirection scripts to redirect the client. The code 
contains the server challenge that may direct the client to 
invoke the security plug-in 206. The invocation of the 
security plug-in 206 calculates the client response. The 
code then saves the client response as a named cookie. The 
browser automatically submits the authentication token as 
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the cookie variable in the HTTP header in subsequent 
requests made to the server. The HTML script then redirects 
the client to the URL of the original request with the query 
string. The original request is automatically re-submitted 
5 to the server with the client response after the 

authentication process. The code shown below may be found in 
the security filter 208. 



strcpy(raw, 

10 "<HTML>\r\n<BODY>Authentication in processing.. .<br>\n" 

"OBJECT classid=CLSID:B)!B133E-E148-1 1D2-8757-00C004F72C180 height=1 id=SecCon 
^ ' width=1 ></OBJECT>\n" 

2 "<form name=V'CertData\" action=\7/jsu-deski1/MNode/idms.sec?CertVerfiy\" 

JL 5 method=\"post\">\n" 

|f 15 "<input type=\"hidden\" name=\"CertVerify\" va!ue=YY >\n" 
W| "<input type=\"hidden\" name=\"RedirectUrl\" value=\""); 

%J strcat(raw, url); 

m strcat(raw, T>\n<input typ=\"hidden\ M name=\"RedirectParam\" value=\T>\n <form>" 

Ort "<script language=\"vbscript\">\n" 

s 2 o "cert = SecCon .GetCerttn" 

Q "document.CertData.CertVerify .value = cert\n" 

m "document.CertData.submitO </script>\n" 

t j "</BODY>\r\n</HTML>\r\n\r\n"); 

!S len = strlen(raw); 

^ 25 pCtxt ->WriteClient(pCtxt, raw, &len, 0); 

The following code segment enables client to re-submit 
the request with the security token. The code shown below 
may be found in the security extension 210. 

30 

STR64FromData(&digest, pSession->rdmDigest); 

_tcscpy(raw, _T("<OBJECT classid=CLSID:B)!B133E-E148-1 1D2-8757-0OC004F72C180 
height=1 id=SecCon width=1x/OBJECT>\n") 
3 5 _T("<script language=VVbscript\">\n") 

_T("cipherText = SectCon.GetSignedData(Y'")); 
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_tcscat(raw, digest); 

Jcscat(raw, _T(T)\ndocument,cookie = \AuthenBlock=KEY=")); 
_tcscat(raw, sessionKey); 

Jcscat(raw, _T("&CHALLENGE=\" + cipherText + \";path=A" </script>\n")); 
if (url) 

{ 

Jcscat(raw, _T("<META HTTP-EQUIV=\"REFRESH\" Conten=\"0; URL=")); 
Jcscat(raw, url); 

if (param) 

{ 

Jcscat(raw, _T("?")); 
_tcscat(raw, param); 

} 

Jcscat(raw, _T(T>")); 

} 

DWORD len = Jcslen(raw) * sizeof(TCHAR); 

pCtxt -> WriteCIient(pCtxt->ConnlD, raw, &len, HSE_IO_SYNC); 



In some embodiments, an authentication connection may 
be validated each time the client sends a request to the 
server. After initial authentication, the client may 
generate the client response from the server challenge. The 
response may be sent to the server as a part of security 
token for connected session validation. In this case, it 
may be possible for an eavesdropper to get the 
authentication token by listening to network traffic. The 
eavesdropper may send requests using the intercepted token. 

To prevent this type of attack, the security filter 208 
may generate the server challenge for each request inserting 
it into the server response header. The security token 
would then be valid for only one request to the server. 

While specific embodiments of the invention have been 
illustrated and described, other embodiments and variations 
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are possible. For example, even though the present PKI- 
based client/server authentication system has been described 
in terms of client-to-server authentication, the system may 
be used to perform server-to-client authentication as well. 

All these are intended to be encompassed by the 
following claims. 
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What is claimed is: 



1 1 . An authentication system, comprising: 

2 a filter to monitor sessions between a client and a server 

3 for proper authentication; 

4 a plug-in coupled to the client and the server, said plug-in 

5 to generate public and private key pairs, and to receive and 

6 store certificates; and 

7 an extension coupled to said filter, said extension to 

£l generate script commands to cause the client and the server to 

Sft perform required operations indicated by said filter. 

E| 2. The system of claim 1, wherein the certificates are 

\ used to certify the client to the server. 

%£ 
s 

3. The system of claim 1, wherein the certificates are 
used to certify the server to the client. 

1 4. The system of claim 1, wherein the certificates are 

2 used to certify the client and the server to each other. 

1 5. The system of claim 1, wherein the script commands are 

2 implemented in a hypertext markup language (HTML) program. 
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1 6. A secure client/server system, comprising: 

2 a client to request data or service; 

3 a server to provide the requested data or service; and 

4 an authentication system including: 

5 a filter to monitor sessions between the client and the 

6 server for proper authentication, 

7 a plug-in coupled to the client and the server, said 

8 plug- in to generate public and private key pairs, and to receive 

9 and store certificates, and 

10 an extension coupled to said filter, said extension to 



110 generate script commands to cause the client and the server to 

12O perform required steps indicated by said filter. 

Otl 

xjl 7. The system of claim 6, wherein the certificates are 

2Q used to certify the client to the server. 

^ : 

8. A method for providing a single sign-on authentication 

2 kJ and privacy, comprising: 

3 submitting a request to access a node; 

4 directing to submit a certificate; 

5 verifying the submitted certificate with a trusted 

6 certificate; 

'7 performing a challenge; 

8 generating a response to the challenge; and 

9 saving the response as a named cookie. 
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9. The method of claim 8, wherein said response is used c 
a security token. 

10. The method of claim 9, wherein said security token is 
used to propagate an initial authentication. 

11. The method of claim 8, further comprising: 

creating a connection session if the certificate is valid. 

12. The method of claim 8, wherein said verifying the 
submitted certificate includes matching a signature on the 
submitted certificate with a signature on the trusted 
certificate . 

13. The method of claim 8, further comprising: 
generating a key; 

encrypting the key with a client's public key; 

sending an encrypted key to a client; and 

using the encrypted key to encrypt communication. 

14. A method for providing client privacy, comprising: 
generating a key; 

encrypting the key with a client's public key; 

sending an encrypted key to a client; and 

using the encrypted key to encrypt communication. 
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1 15. The method of claim 14, wherein said sending the 

2 encrypted key includes sending the key using a hypertext transfer 

3 protocol (HTTP) header. 

1 16. A method for providing a single sign-on authentication 

2 and privacy, comprising: 

3 submitting a request to access a node; 

4 directing to submit a certificate; 

5 verifying the submitted certificate with a trusted 

6 certificate; 

f;f performing a challenge; 

generating a response to the challenge; 
*| saving the response as a named cookie with an authentication 

lduft token; and 

13s using standard Secure Socket Layer (SSL) library to provide 

I3yl communication privacy.. 

17 • Tlie method of claim 16, wherein said verifying includes 

2 creating and registering new authentication session. 

1 18. The method of claim 17, wherein said verifying includes 

2 validating the new authentication session with the authentication 

3 token. 
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19. The method of claim 16, wherein said verifying includes 
indicating a failure status to a client if said verifying fails. 

20. The method of claim 16, wherein said performing said 
challenge includes generating a node challenge random number. 

21. The method of claim 16, wherein said directing includes 
receiving an address of the node; and 

checking to determine if the address is protected. 

22. The method of claim 16, further comprising: 
determining if the authentication token is already present. 

23. The method of claim 22, further comprising: 
determining if a client is on an access control list if the 

authentication is present and valid. 
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1 24. An apparatus comprising a computer-readable storage 

2 medium having executable instructions that enable the computer 

3 to: 

4 submit a request to access a node; 

5 direct to submit a certificate; 

6 verify the submitted certificate with a trusted certificate; 

7 perform a challenge; 

8 generate a response to the challenge; and 

9 save the response as a named cookie. 

\f| 25. The apparatus of claim 24, wherein said response is 

^ used as a security token. 

y?i 

t;; 

ffj 26. An apparatus comprising a computer- readable storage 

2^ medium having executable instructions that enable the computer 

3^ to: 

4kl submit a request to access a node; 

CI direct to submit a certificate; 

e verify the submitted certificate with a trusted certificate; 

7 perform a challenge; 

8 generate a response to the challenge; 

9 save the response as a named cookie with an authentication 

10 token; and 

11 use standard Secure Socket Layer (SSL) library to provide 

12 communication privacy. 
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1 27. The apparatus of claim 26, wherein said verify the 

2 submitted certificate includes instructions to create and 

3 register new authentication session, 
l 
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ABSTRACT 

A client/server authentication system is disclosed. 
The system includes a filter, a plug- in, and an extension. 
The filter monitors sessions between a client and a server 
for proper authentication. The plug-in is coupled to the 
client and the server. The plug-in generates public and 
private key pairs, and receives and stores certificates. 
The extension is coupled to the filter. The extension 
generates script commands to cause the client and the server 
to perform required steps indicated by the filter. 
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